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(54) Method and apparatus for telecommunications using internet protocol 



(57) In . a wireless packet switching 

telecommunications network, voice services are provided 
by having a compressor/decompressor (64) in each mobile 
station (60) to provide each voice packet with a 
compressed header. Voice data and signalling data are 
sent separately and in different data formats to the air - 
interface (61). The compressed header may be an M bit 
and a cyclically reset timeclick_number t which is 
decompressed by use of a wallclock which counts reset 
cycles to reinstate the voice packet headers 
Alternatively, RTP agents are provided at the 
compression and decompression points, and voice 
packets are sent without headers over a "high quality" 
network such as a frame relay or ATM network 



Compression state of a voice packet header can be 
established by sending call set-up information over an. 
out-of-band channel between compression points in a 
mobile station and in the network. 
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Description 

Abbreviations 

[0001] The following abbreviations are frequently used in the draft: 

PSTN: Public Switched Telephone Network 

TCP: Transport Control Protocol 

UDP: User Datagram Protocol 

RTP: Real Time Protocol 

IP: Internet Protocol 

VoIP: Voice Over IP 

CD: compressor/de-compressor 

CDMA: Code Division Multiplexing Access 

MAC: Medium Access Control 

RLC: Radio Link Control 

GSM: Global System for Mobile communication 

GPRS: General Packet Radio Service 

1. Field of the invention 



K*> to ^'S!^!^T miCMm ? ° pwa,lns a swilling technology. » "oolo odvantagoous.to 



2; Brief Description of the Prior Art 



K Lrnks^RrcS; %n'mnT« y r S C TS a "l V JaCObson; ^^P^s.ng IP/UDP/RTP Headers for Low-Speed 
wfftfL * ' ?' ft P //ft P | S'-edu/in-notes/rfc2508.txt is to compress the RTP/UDP/IP headers A nmtn^i ,c 

■nSi^SSffS ^SS^^^'J^ •» must be re-transmitted and the provision, of an error- 
3. Summary of the Invention 

E, .p^,^^ 8 ^ 60 ^ ****** station for a P acket switching radio network which includes a Voice over 
Internet Protocol applrcabon layer and Internet Protocol Stacks including Real Time Protocol. Transport ConS 
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Protocol, User Datagram Protocol and Internet Protocol layers, further comprising a compressor/decompressor to 
compress voice data, and means to send voice data and call signalling data separately and in different data formats to 
the link layer and the air interface of the mobile station. 

[0007] In one arrangement the compressor/decompressor is arranged between link layer (which is above the physical 
layer in the air interface) and the IP layer, and receives both the voice data and the call signalling data. 
[0008] In an alternative arrangement the compressor/decompressor is arranged between the air interface and the 
VoIP applications layer, and receives the voice data. 

[0009] Also according to the invention a packet switching radio network comprising a plurality of mobile stations 
as defined above and at least one network element in which there is compressor/decompressor means arranged to receive 
signals relating to compressed voice data. 

[0010] Further according to the invention a method of operating a packet switching radio network to provide voice 
services comprising separating the voice data from the call signalling and other data, whereby each voice packet 
containing voice data can be provided with compressed or removed RTP/UDP/IP headers. 

[0011] Yet further according to the invention, a first method of compressing and decompressing headers for a packet 
switching network comprises providing in each compressed header a cyclically-reset timeclick_number representing the 
sampling time of the packet payload; increasing the timeclickji umber by 1 for each sample duration time, counting the 
reset cycles, and from the count of reset cycles and a received timeclick_number, providing a sequence number and 
timestamp for providing a decompressed header. 

[0012] Yet further according to the invention, a second method of compressing and decompressing headers for a 
packet switching network comprises removing combined RTP/UDP/IP headers and placing data in RLC/MAC payload; and 
decompressing received packets by use of an internal clock to obtain a timestamp value, and increasing the sequence 
number by 1 for consecutive packets. 

[0013] Also according to the invention, a method of establishing a compression state of a packet header in a packet 
switching network by making use of call set-up information over an out-of-band protocol. 

4. Brief Description of the Drawings 

[0014] The invention will now be described by way of example with reference to the accompanying drawings in which: 
Figure 1 illustrates a wireless packet switching network based on the UMTS model. 
Figures 2a and 2b shows two embodiments of the invention in a mobile transceiver; 
Figure 3 illustrates an entire communication channel; 
Figures 4a and 4b illustrate alternative compression algorithms; 
Figure 5 shows establishment or re-establishment of compression state; and 
Figure 6 shows inter-compression point handover. 

5. Description of a Preferred Embodiment of a Mobile Station and Network 

[0015] In Figure 1 , a wireless mobile telecommunication system 10 comprises a number of Mobile Stations (MS) 12 
and a number of base transceiver stations (Node B) 14 connected through a RNC (Radio Network Controller) 1 6 (all in the 
Radio Access Network RAN 18) to a packet Core Network (CN) 20 which consists 6f two elements: a SGSN (Serving 
GPRS Support Node) 22 and a GGSN (Gateway GPRS Support Node) 24. The CN is connected via a IP/PSTN Gateway 
26, to the PSTN (Public Switched Telephone Network) 30 and to the Internet 28 
[0016] In this Figure the network architecture is based on the UMTS reference model 

[0017] Suppose the network 10 operates in packet switch mode. One way to implement voice service is to use VoIP 
technology in which VoIP application from the mobile station 12 is treated as a general IP application and coded voice 
is decomposed into RTP/UDP/IP packets and transmitted over the air, the RAN 18 and the CN 20 to Internet 28 or the 
PSTN 30 via the IP/PSTN gateway 26 

,[0018] At a mobile station 12, IP-based call signalling and the Graphical User Interface of VoIP application can 
run iri ; the same way as on a normal IP terminal. The voice traffic is sent as a link layer payload with compressed or 
removed RTP/UDP/IP header information, as will be explained in more detail below 

[0019] Referring to Figure 2a, the up-lmk direction is considered from a mobile station 60 to the network. In the 
mobile station there is: a VoIP application layer 68 from which call signalling data is sent to a TCP layer 66 and a 
UDP/IP layer 65. Voice da 

[0020] Both call- signalling data and;; voice data in packets are provided to a compressor 64, which compresses the 

combined RTP/UDP/IP headers, but the compressor does not compress the call signalling data. The two types of packet 

62,63, (compressed and uncompressed) are put in RLC/MAC protocol, and pass over the air interface 61. 

[0021] To receive voice and call signalling data (the downlink direction) the process is reversed 

[0022] In the alternative arrangement for a mobile 70 shown in Figure 3b, the compressor 74 sends/receives the 

voice data 63 to/from VoIP application 78 while call signalling data 62 passes through normal IP layers 75, 76 
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[0023] It can be seen that in both arrangements the voice and call signalling data are separated. 

[0024] Figure 3 illustrates a whole system, in which a mobile 60 with its compressor 64 is connected through the 

air interface 61 sequentially to a Radio Access Network (RAN) 81 which tunnels or relays data between the air interface 

61 and the Core Network 84, and a decompressor CD 83 in CN 82 connected to any IP host 85 via the Internet. 

[0025] In the arrangements shown in Figures 2a, 2b and 3, it is assumed that the IP/UDP/RTP header information is 

not used for routing etc, from the mobile station 60 to the CD 83 in CN 84; instead all data including voice packets are 

relayed/tunnelled. It is assumed that the packets are delivered in sequence between the mobile 60 and the CD 83 It is 

further assumed that some mechanism will be able to distinguish compressed (speech) packets from normal 

(uncompressed) packets, and this distinction can be maintained until CN 84 is reached. 

[0026] The arrangement described may achieve a level of radio efficiency which is of a similar level to a circuit 
switched voice service provided by wireless.telecommunications systems such as.GSM. . 

[0027] It is a further advantage that no error recovery mechanism is needed, and there is no inter-packet 
dependency for decompression, so packet loss does not cause malfunction of the compression point. 
[0028] The VoIP applications 68, 78 run as if they are accessing a normal IP network although the voice packets are 
treated differently along part of their journey — from the MS 60 to CN 84. Also, from the viewpoint of the other IP 
endpoint 85 (a user terminal or a IP/PSTN gateway), the elements in the RAN 81 (MS 60, Node B and RNC 80) are treated 
as a set as a endpoint, because the voice frames (data 63) need to travel a relatively long way before being RTP-framed 
at CD 83. 

[0029] General benefits of the arrangement are that there is higher compression gain and saving of resources; that 
the system operates when the round-trip-time between compression and decompression is long; and that the benefits 'from 
IP-based call signalling can be kept. 

6. Description of Two Preferred Algorithms 

[0030] There are two compression algorithms for IP/UDP/RTP headers, one can be characterized* as a "best-effort 
lossy compression" and another one can be characterized as "Zero header compression". Both algorithms are based on 
the fact that the IP/UDP/RTP headers are not used between MS 64 and CN 84. 

6a. First Preferred Algorithm 

[0031] The objective is to break up the interdependency of the compressed packets. Instead of sending relative 
values in the compressed headers (by differential coding), absolute values (timeclick numbers) are sent as suggested by 
Petrack. As there is no inter-relationship between compressed RTP packets, packet loss will not stop decompression from 
operating. 

- Using the first algorithm the compressed header can be only 1 byte, in comparison with 2 to 5 bytes in a known 
arrangement. The most important information in RTP header, the two time related fields — timestamp and sequence 
number, need to be retained. As pointed out in the paper by Petrack referred to above, these two fields can be 
replaced by a "timeclick number" (in one= byte). This number assists the decompressor to put a proper timestamp 
(reflecting the sampling time at the mobile station 60) and sequence number. The publication suggests that instead 
of the conventional timestamp and RTP number, a single 1 byte "timeclick" number is sent with each packet However, 
in the prior publication there was no disclosure of how to recover the timestamp and sequence number or how to 
establish compression states out of band . 

- It is assumed that there is only one VoIP session requiring compression per terminal, thus no CID ;(Context ID) bits is 
required. The M bit in RTP header is kept and transmitted with each compressed packet 

[0032] Compression-state, first algorithm. The compression state contains the Mow information for a call 
(consisting of two RTP sessions) to be compressed: for each call-end: IP address, two port numbers (sourcing and 
incoming), SSRC etc, for the call: the codec used and its parameter (e.g. sampling rate: and sample duration). The codec 
for both directions is assumed to be the same. (If not then need to store them separately). 

[0033] The establishment of the compressibrvstate is via an out-of-band protocol, which can work together with the 
call signalling protoail, and will be described later. This protocol will also help to migrate the state information 
from one CD to another one in the case of handover between CDs 

[0034] Compression process, first algorithm. Through the compression, three fields will be preserved in a nearly 
lossless way: timestamp, sequence number and the M bit A byte (8 bits) is used for the compressed header: the first bit 
is used for the M bit, and the other 7 bits for timec!ick_ number, which represents the sampling time of the voice 
payload contained in the. pac^ coding. It will 

continue to be increased even in the silent penod when no packets are actually sent out 
[0035] The fields whose information may become inaccurate through the compression are- 

- The packet ID in IP v4 It is assumed that the packet ID field always increases by 1 so it does not need to be 
communicated . When packet loss is detected the ID. value is set accordingly. As not air packet-loss can be detected 
so the ID! value may become inaccurate; 
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UDP checksum field. The checksum field is not used (set to 0) from mobile terminal 60. If it is used on the down- 
ink direction, it is set to 0 by the CD in the network (and then the end-to-end error detection for applications 
that require it is disabled). Thus the error correction using the UDP checksum will be disabled. 

RTP CSRC list. For the uplink direction, the CSRC list should always be empty. For the downlink direction it mav 
change (e.g. in the case of conference call). For 2-party call, it will be unchanged (empty). ' 

Sequence number. In the case of packet loss between the mobile station and the RTP proxy, and the decompressor 
of the SaSS iSZSSSESZ by fce RTP Pr0Xy iS inCOrreCt ' WhiCh ™* influence the «™ <* 



[0036] There are two modes of accessing the compression service. One is accessed by the VoIP application directly 
S« S £ m F ' 9 T 3(b)) ' f b r paSSir l? the transport and networi< ,a y ers - 106 obvious is the efficiency Srt 

Spresl^rbe? 3 " 96 aPP 00 ° r ^ 3 franSPOrt ' ayer Wrap UP - The Service access Primitive for the 

compress (M, timeclick_number, voicepayload) 

fnn«l 11 iS strai 9 htforward to generate a compressed RTP packet with these three data items 
Sn„2 v*^**!^ the , com P ression can be accessed by the network layer in a transparent way (as shown in 

it t £ r PP ! r ,ayefS are !i nkn0Wn about the ""Wton- m this case, upon receivhg a packet from uppTr 
J 1 c 2?£ 8 tna fields of s o"^/destination IP and port number also the source SSRC These five fields will 
iffStf t R J P t SeSS, °p n T r d b l CheCkin9 tnese field a9ainst the compassion-state table, it is SriSSJrS'SSi 
K is a RTP 'n^t , ^ PaCk6t WhOS ! State already establ *hed), or treat it like non-RTP. nomiriSSS 

primitive Sn bSd COmpreSsed ' the tenMton P fie,d is ™PP«* to a timeclick-n umber. Then the above service 

[0039] For the downlink direction, if the UDP checksum is used (non-zero), it will be ignored 

[0040] After a compressed RTP packet is generated, it is put in a link layer packet together with a marker tellino 
packet SP ' non-compressed packet will be put into a link layer packet marking SasTeSdate 

Decompression process, the first algorithm. 

[0041] Except for the time-related RTP header fields, recovery of the other fields are from the compression state 
using a similar approach to RFC 2508. wmpresson siaie 

Tha 2 Lu, F °l the " mestam P fiel <! : tne ma j° r Problem to solve is that the field for timeclick number is only 7 bits 
a^leToSc T7^ C ^^^^^J mP '' m ^ (reS6t Periodically) during a single telephone call) During 
«£fi£^ by C ° mpreSSOr ' "» time 6teps6d for this -' lent period * terms of how 

2Sf3'' .• 'n the first, algorithm according to the invention, a computer clock at the CD 84 is used to count the cycles 
^ "iK^ ' S used / with reference to : the clock reading, to set the timestamp field. The clock can rUn at 
tU° tm 9 h ?, anty - l° T eXamp ' e Ca " be increased b y 1 for ever V T/4 P en 'od assuming the maximum jitter isTeS 

' " ^ Peri ° d0f aCyC,e repreSented * 7 b «* * is -iy sevS 
K!L „IwT 9 ^ t0 . the seau ence number, this number is normally increased by 1 for each consecutive packet It 
to S2 3S?2S£?l! ^ ^tofjn fhe first algori heuristic method Is' used 

W'2S?h w,* l0S n by Recking both the .ncreases of timeclick number and the M bit. If the timeclick number is 
SS3 EL SS^'* 6 ^ °K ne (Say ^ etc ) b "t the M bit is not set, then there is :. £525^ 
K"ft?t"££TJ f ^tf 1 "^""^^ ,nc T ease ^ by the difTe^ence;of trie timecJick number. In the case of the 
£ he S6t u M b,t 9 e ts lost (then the. bigger increase of timeclick number is normal, as it is silent 

SE^feS* fl ^-«W.^-.l» *«tf«w*-ljy'1. The. probability for this situation to happen is quite 

small. Even rf this happens and the sequence number is increased by mistake, it will slightly influence me statistic 
result of packet-loss rate perceived by the other RTP end (a few more packets are reported tobelpstj 

Denotation; V .: •= ■ '•' 
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JSIast: Timestamp number for the previous packet 

TSthis: Timestamp number for this packet 
WTIast: Wallclock reading for the previous packet 
WTthis: Wallclock reading for this packet 

TWast: Timeclick number of previous packet in compressed header 
TUthis: Timeclick number of this packet in compressed header 
SWast: RTP sequence number of previous packet 
SNthisL: RTP sequence number of this packet 

T: the time period represented using nb bits (a cycle period), in units of sample duration (sd) 

T = 2**nb 

M: the value of the "M" bit, in compressed header 

[0046] Calculating the timestamp and sequence number: 

TSthis = Ts/atf + 1 , if M ■» 0 and deltatick = 1 

= Tslost + (delta_cycle*(2**nb) + delta_tick)*sd*sr/1000, 
otherwise where: 

delta_tick - (T + Tnthis - Tnlast) mod T 
delta_wtick = Wtthis-Wtlast mod T 
delta_cycle = (Wtthis-Wtlast)/T/*integer part*/ 

delta_cycle = delta_cycle r -1 if delta wtick < delta tick and delta tick- 
delta wtick >= T/2 

deltajcyde 9 ' +1 ,if delta _tick < delta_wtick and delta_wtick- 

• = delta_cycle\ otiierwise ' 
Snthis = SMast + delta_tick, if deltajick !=1 and delta^tick < 4 and M !=1 

6b. Second Preferred Algorithm 

[0047] The second algorithm for header compression is now described; the header may be zero. 
[0048] In some cases, for example, GPRS (General Packet Radio System, an overlay packet network over GSM 
system); the radio bearer channel is desigfnedjh such a way that if is. hard to put any e*tra header information together 
with speech data Thus we would like to investigate if it is possible to transmit voice in "raw" format (speech only),: 
but still keep most of the benefits from IP telephony (e.g. IP based call signalling thus enable CPL, web-based call etc). 
.: [0049] The basic jdea of this solution, : as shown in. ~Flgijra\i4l^- jte ^ tti^v^^8l!derina--ttiat - jfcici .^pojVi . between mobile 
station 60 and; CN 84 is over a controlled packet network (over frame relay or ATM, for example) and certain QoS will be 
provided (no mi3-prdering, the jitter and; packet-ioss-rate are small so that the voice quality will not suffer on this 
path), it is possible completely to: remove the IP/UDP/RTP headers between mobile station and CP and use a box callied 
RTP agent as the decompressor in CN. v • 
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- In this case the RTP agent (up line direction) performs a role similar to the IP/PSTN gateway: for the up link 
direction, the voice frames from a mobile station are transmitted without any IP/UDP/RTP headers, in a way very 
close to the circuit-mode voice in wireless networks, e.g. in GSM, (but is over a "good" quality packet network) up 

( to the RTP agent which adds proper headers and sends them off to VoIP networks. On the downlink direction the RTP 
agent strip off the headers and transmit them up to the mobile station. 

5 

[0050] Using the second algorithm, the benefit of IP based call signalling and service, creation is retained At the 
same time there is the benefit of high radio resource efficiency. On the other hand, the mobile terminal may lose some 
capability relying on RTP header information; for example to find the packet-loss-rate and packet delay, and the olav 
buffer may be adjusted accordingly. . 7 
10 I 0051 l Th e major differences between the first and second algorithms are that, when using the second algorithm: 

- On the mobile station, the VoIP application loses the chance of using any time-related information in RTP header 
For example to detect ^the packet-loss and calculate the jitter. Note that the compression itself will not introduce 
extra packet-loss and jitter. It would be difficult to generate proper RTCP packets but can ask RTP agent to do this 
job on its behalf. 

15 

- From the viewpoint of the other IP endpoint of the call (a user terminal or gateway), the packet loss detected by 
the RTP agent (and reflected in the fields of sequence number and timestamp) may be less accurate than the first 
algorithm. 

20 [0052] The way that the CD in the second algorithm adds on (up link) and strips off (down link) IP/UDP/RTP headers 
is similar to that used in a general IP/PSTN media gateway. The differences are: 

- The general media gateway normally has two network interfaces: one for PSTN and another one for packet network 
(e.g IP ATM). It translates media between circuit-mode and packet-mode. RTP-agent has two network interfaces both 

25 of which are for packet network. 

- In general media gateway, the voice coming from the PSTN side is continuous and its rate is constant In our case 
as voice frames are transmitted over packet network on both sides, it needs to do more; to try to detect the packet 
loss in order to put on correct sequence numbers and timestamps by examining the inter-arrival time of the packets 
from RAN side; it may need to send RTCP packets on behalf of the mobile terminal. 

30 

[0053] Compression-state, second algorithm. This is the same as in the RTP-proxy approach. 

[0054] Compression process, second algorithm. The compression process is very simple: it just strips off any 

header and puts the speech data only into RLC/MAC messages. The service access primitive for the compressor can be:. 

35 compress (voicepayload) 



No 



45 



50 



55 



[0055] Like in RTP-proxy approach, the compression service, at the terminal, can be accessed by the network layer 
in a transparent way. In this case, upon receiving a packet from the network layer, it checks the fields of source/dest 
IP and pot number, also the source SSRC. These five fields will identify a RTP session and by checking these fields 
against .. the, compression-state table, it is : decided either to compress the packet (if it is a RTP packet whose 
compression state already ^ established), or treat it like non-RTP, normal packet: If it a RTP packet to be compressed 
the headers are strip off and the above service primitive can be called '■' 
[0056] For the downlink direction, the CD in the network checks each packet to see if it belongs to a RTP session 
being compressed. If yes the RTP/U DP/IP headers are stripped off and the speech data is put into the payload of for 
example, the tunnelling protocol address . / 

[0057] . Pecompression process, second algorithm. At the decompressor in the network (CD 84), a computer clock 
js used. , As for the first algonthm, the major problem is how to recover the time-related fields. There are two ways to 



(a) 



The decompressor checks at the beginning of every sampling; duration period (the period covered by the speech 
frame s) earned by an RTP packet; for example it will be 20ms if each RTP packet carries one GSM6 10 speech 
iSml/p™^ 6 - IS T V ^ m P re ^speech packet coming from RAN; If W the decompressor adds 
IP/UDP/RTP headers on the packet. The decompressor maintains a small buffer for incoming speech packets 
from RAN to smooth out the jitter • • 

The^dec»mpressor obtains the timestamp value from the internal clock (translated to the sampling time format as 
used in RTP) The sequence number is increased by 1 for each packet 
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(b) 



- Alternatively, the decompressor checks the inter-arrival time of each compressed packet arriving at the RAN 
A 9 ftpr SS th 1 ^ ' S any ^ ckeWoss ' considering the variation of delay aSd the possibility of stent 
penod After this analyse .s performed, if the packet just arrived is thought as the consecutive ariS! 

tkL S det t nrn, ! 1ed scheme used, on the top of the timestamp value of the previoS 0 S 

KS3^T b9r ,S add6d by k" 6 ° n the top of 1,16 seouence number of «» previous packet ffiSlfES 
is inferred then the sequence number and timestamp will be increased accordingly to reflect the can wt 

SdfiS? 3 Si ' ent Peri ° d " infeTOd> ^ SeqUenC6 number iS added b * " ^IlSii'nifS 

SL^X^f ^ and second Preferred algorithms have been described with reference to a packet switchina 
radio network, both algonthms may also be applied in other circumstances where the following features hold: sw,tcr,,ng 

" IrenoTulll***™**" * ' P n *™ k h 3 P«***>-P°M like connection over which the IP headere 

" l^UelZ^or^ in - 0rd6r Sma " ^ S ° me head - accuracy pointed out before 

7a. A preferred process of compress-state establishment and re-establishment 

[0059] The compression-state establishment process is used for several purposes/occasions: 

* ^mpreSfoa 9 * * ^ com P ression - state *> be established to start compression and 

" anZtom^oMC™ ha ™ ens - th « co ^ s ™-s**e needs to be migrated to the new CD from mobile terminal 

ofRTP funpf JSEJ nlS te H°K ntainS tte I f oltowin 9 ^formation: IP address and SSRC for both call ends, two pairs 
ot K rp (upP) port numbers, payload type, sampling rate, sample duration, etc 

separately: *• * — ^ ^ ^ f ° r directions are the same, otherwise they need to be stored 

SSS i _: Tne compression state establishment and re-establishmeht are done using an out-of band protocol which is 
shown m. Figure 5. which shows a mobile station compressor 90 connected to a VoIP call control layer 92 ^nder mird 
%Z£Tl a £%^^^ SS T 0 *^ " etWOrk compressor 96; and the JS^Sfc are conneSS 

[0063J All the CDs 90, 94, 96 are in reality compressor/decompressors 

'SSfU- a ,J!l e ( ? S 9 ,° at ^ e mobile station and 94 in the network have a control interface. Both CDs listen on a known 
^££ c< *2 to stert/stop- compression i and receive state ihfbrmatioh from the thirf party ^ Typically the 

•nstrucbon and nforiTBhon come from the voice application at MS and/or signalling gateway (e.g: £+323 GatKer or 
^^t^T ^ ^ netWOrk - ***** ■» addreS of the 'sewing Cr! ? is 

SedgS ^ P ° ^ 3 W party ^ or between two CDs (not including the : 

co'S^l^^fe?H? inolcates^at anew compression session and its state is to be established. It should 
SET* J f S ty ^ being involved in the session. As an option it can contain a full (uncompressed) RTP 

packet so that the compression state information can be extracted from it lunwmpresseoj n i k 

valu S e)paf JNPUT ^* meSSa90 prpv,des or mod,fies va,ues of ^ attributes It contains a list of (attnbute.name, 

£jS21]^^^ two messages can be used to inquiry the state information and 

to know if it is ready to perform compression/decompression tasks. • 

4. STATE_HANDOVER. This message informs a current serving CP to send state information to a new CP, or asks a 
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new serving CP to acquire state information from a previous serving CP. The message contains information bout the IP 
address of old and new CPs and the identity of the MS involved. 

5. STATE_STOP. This message deletes a compression state. A compression can also be deleted by compressor itself 
when necessary. 



[0066] The message STATEJNPUT is also used between the compressor 90 at MS and the CD 94, 96 in network to 
exchange state information. So the information available at one end will be 
available at the other end by using this protocol. 

[0067] The messages STATEJNPUT and STATE_ENQRY are also used for moving state information from one CD to 
another in the case of handover. Apart from the state elements listed above, some extra information such as local clock 
reading is also exchanged to the new CD. 

[0068] It is allowed for^the compressor to pick up values or use default values for some attributes in some 
circumstances. 

[0069] This process also supports the state re-establishment between CDs at MS and in network. This is necessary 
when the state information is damaged or lost at one side. Once the compressor at CD or MS detects the miss or 
incompleteness of state information, it can use STATE_ENQRY to obtain the state information from the other end. 
[0070] While the inventive process of establishing or re-establishing compression state has been described with 
reference to a packet switching radio telecommunications network, the process may also be used for any compression 
process for a connection oriented application such as VoIP and multimedia sessions. 

8. Two preferred processes for handover between two compression -points 

[0071] One problem to use the compression scheme presented in RFC2508 within wireless networks is the impact of 
mobility. When a handover occurs, it is possible that the serving CD will change. So the compression states stored in 
the CD before handover have to be moved to or re-established at the new CD. 
[0072] Two alternative approaches are proposed to cope with this problem: 

• Firstly, we can arrange some communication between two CDs so that they can exchange compression states, as 
shown in Figure 6 in which a mobile station having a compressor 104 is handed over from a serving CD in network 106 
to a new CD 108 in network. The serving and new CDs 106, 108 are provided with an out-of-band communication 
channel 110. 

One way is to share the compression state information among, a group of CDs (which may potentially become the 
serving CD after handover), so that when handover happens the necessary compression context already ready in 
the new CD. The cost of this method is the CPU time and memory required to receive/store the context which may 
not be used at all. 

Another way is to exchange the contact information during handover. To apply this approach, we need the co- 
operation from the handover mechanism so that the exchange of compression states information can be triggered 
' when the CD is changed. 

- A third way is to make use of soft-handover feature available in CDMA networks. The exchange of context can be 
performed during soft-handover period. This approach requires the co-operation from the radio network so that 
the two CDs can be informed when a soft-handover happens. . 

To allow the decompression process at the new CD, trie exchange of compression-state information should' 
: ; include the timestamp value and sequence number value in the last decompressed RTP packet by the previous 
CD. The two computer clocks at the previous and new CD need not be synchronizedi Wheh the new CD start to 
serve the RTP session handed over, it read its own clock and uses the reading as the clock reading for the last 
packet. . , ■■' ,. 

:•' Secondly, as in UMTS and GPRS situation, the user IP will not be used until the point to leave CN for backbone 
• •: network(a tunnelling protocol is used to transport user packet between BSS and CN) Therefore we can make use of 
this feature and put CP at the edge of CN, for example at GGSN so that the CP is transparent to the handover. In 
particular, by moving the CP into CN, the CP and the IP/PSTN gateway, which is required to make use the VoP service 
network, can be integrated. The drawback of this approach is the possible performance bottleneck at the CP in 
network: : • 



[0073] Several modifications of the present invention will become readily apparent to those skilled in the art in 
the light of the foregoing discldsure. Therefore, the scope of the present invention should be interpreted from the 
following claims, such , claims 
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Claims 

1. A mobile station for a packet switching radio network which includes a Voice over Internet Protocol application 
layer and Internet Protocol Stacks including Real Time Protocol, Transport Control Protocol, User Datagram Protocol 
and Internet Protocol layers, further comprising a compressor/decompressor to compress voice data, and means to 
send voice data and call signalling data separately and in different data formats to the link layer and the air 
interface of the mobile station. 

2. A mobile station according to Claim 1 in which the compressor/decompressor is arranged between the link layer and 
the IP layer, the compressor/decompressor receiving both the voice data and the call signalling data. 

3. A mobile transceiver according to Claim 1 in which the compressor/decompressor is arranged between the link layer 
and the Voice over IP layer, the compressor/decompressor receiving the voice data. 

4. A packet switching radio network comprising a plurality of mobile stations according to any one of Claims 1 to 3 
and at least one network element in which there is compressor/decompressor means arranged to receive compressed 
voice data. 

5. A network according to Claim 4 in which the compressor/decompressor is arranged towards the edqe of the core 
network adjacent the backbone network. 

6. A network according to Claim 4 or Claim 5 in which the voice and data packets are routed through the Internet. 

7. A network according to Claim 5 or Claim 6 in which the voice and data packets are routed through a gateway to the 
public switched telephone network. 

8. A method of operating a packet switching radio network to provide voice services comprising separating voice data 
from call signalling and other data, whereby each packet containing voice data can be provided with compressed or 
removed RTP/UDP/IP headers. 

9. A method according to Claim 8 in which the voice packets for VoIP applications are sent as a link layer payload 
directly without going through IP layers. 

10. A method according to Claim 8 or Claim 9 in which each voice packet header comprises a cyclically-reset 
timeclick_number representing the sampling time of the packet payload; the timeclick_number being increased by 1 for 
each sample duration time; and in which the headers are decompressed by counting the reset cycles by means of a 
separate clock; together with the received timeclickjiumber to provide the sequence number and timestamp of a 
decompressed header. 

11. A method according to Claim 8 or Claim 9 comprising in a mobile station removing combined RTP/UDP7IP headers 
and placing voice data in RLC/MAC payload; and decompressing received voice packets by using an internal clock to 
obtain a timestamp value, and increasing the sequence number by 1 for consecutive packets. 

12. A method according to Claim 8 or Claim 9 comprising, in a mobile station, removing combined RTP/UDP/IP headers 
arid placing voice data in RLC/MAC payload; and decompressing received voice packets by determining packet inter- 

. arnval times/to: detect loss of; any packet and if such loss : is detected, adjusting the timestamp value and sequence 
numbers of RTP headers of subsequently received voice packets accordingly. : 

13. A method according to any one of Claims 8 to 12 in which the compression state of a voice packet header is 
established by making use of call set-up information over an out-of-band communications protocol between a mobile 
station and a compression/decompression in the network. 

14- A method according to' any one of Claims 8 to 13 further comprising providing an out-of-band communications 
protocol between a serving compressor/decompressor in the network and other compressor/decompressors in the 
network, and, on handover of the call, exchanging compression context information relating to a current call between 
the serving compressor/decompressor and a new serving compressor/decompressor. 

15. A method according to Claim 14 in which the exchanged compression context information includes the timestamp 
value of the last decompressed RTP packet. 

16. A method according to Claim 15 in which the network is a Code Division Multiplexing Access network having a soft- 
handover facility, and preparing and performing exchange compression context information during ■ a sbft-hahdbver 

■ ■ period.; 

17. A first method of compressing and decompressing headers for a packet switching network comprises providing in 
each compressed header a cyclically-reset timeclick^numbeir representing the sampling time of the packet paytoad; 
increasing the timeclickjiumber by 1 for each sample duration time, counting the reset cycles, and from the count of 
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reset cycles and a received timeclick_number, providing a sequence number and timestamp for providina a 
decompressed header. y 

18. A method according to Claim 17 further comprising including in each compressed header an M bit; and 
decompressing a header when no M bit is received by increasing the packet sequence number of the decompressed 
header by the difference of the timeclick_numbers between the packet for which no M bit is received and the last 
previously received packet having an M bit. 

19. A second method of compressing and decompressing headers for a packet switching network comprises removing 
combined RTP/UDP/IP headers and placing data in RLC/MAC payload; and decompressing received packets by use of 
an internal clock to obtain a timestamp value, and increasing the sequence number by 1 for consecutive packets. 

20. A second method according to Claim 19 in which the network is a frame relay network. 

21 . A second method according to Claim 19 in which the network is an Asynchronous Transmission Made network. 

22. A method of establishing a compression state of a packet header in a packet switching network by making use of 
15 call set-up information over an out-of-band protocol. 
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